需要咨询或交流或获取电子版本，PPT资源下载地址：92G10SA3 92G10SA3 https ://8ma.co/res/92G10SA3

概述

JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的研发管理工具。其配置灵活、功能全面、部署简单、扩展丰富等超过150项特性得到了全球115个国家超过19,000家客户的认可。

Jira可以做到页面表单自定义、工作流程自定义，丰富的图表数据统计，开放外部API（可与邮箱、钉钉、Git等进行集成，做到消息实时同步）。

Atlassian公司将Jira免费提供给诸多开源项目进行陷跟踪服务，因此在开源领域，其认知度高且易用性好。

1. 需求管理, 子需求管理（一个需求可能拆分成若干个细的需求）

2. Bug管理

3. 需求/子需求和Bug相关联，可以看到每个需求相关的Bug数量及进度

4. 可以根据条件进行搜索，比如说想看有多少Open的Bug, 每个开发人员Fix bug的进度等。

项目：项目是根据你的企业组织需要定制的，是问题的集合。一个项目可以代表一条业务线，一个软件研发项目，一个需求管理系统等等，我们使用是定义为业务线的需求管理

问题类型：可以用于跟踪多种不同类型的问题。系统管理员可以根据需要添加。JIRA系统缺省提供的问题类型如下：BUG、task，Improvement，由于我司需求管理的需求，我们使用是按照产品工单、技术需求、开发测试子任务、UED工单等

自定义问题类型，适应组织管理的需要自定义字段，可选择字段类型超过20种，在此基础上还支持插件进一步扩展自定义问题安全级别，可以限制指定用户访问指定的问题如果多个问题需要同时修改同一字段值或执行同一工作流动作，你可以使用批量操作功能一次性完成登记问题预计完成时间、实际工作时间，就可以了解该问题预计还剩多长时间才能解决。甚至可以出具时间跟踪报告，了解用户的工作效率支持远程创建问题，通过多种方式在JIRA中创建问题，如电子邮件、移动设备客户端如果一个问题需要多人协作，可以将问题分解为多个子任务，分配给相关的用户将相关或有依附关系的问题建立链接，以便于用户快速了解为JIRA的问题添加附件，可以帮助技术人员快速解决问题，当上传图像文件时，JIRA自动显示图像缩略图。你也可以直接将剪切板中的图像粘贴到JIRA问题中为问题设置到期日，可以在搜索或在图表中展示即将到期的问题

工作流：根据自己的需求可以设置不同的工作流程，跟问题类型对应，我们针对每种问题类型都定义了对应的工作流

界面方案：根据自己的需求可以设置不同的界面，如果是非系统默认的需要去创建新的字段

优先级：在 JIRA 系统中用优先级来表示问题的严重级别。系统管理员可以在 JIRA 系统中添加优先级，JIRA 系统缺省的优先级为'紧急'，'严重'，'一般'，'次要'，也支持自定义替换

角色：JIRA 作为一个缺陷跟踪管理系统，可以被企业管理人员，项目管理人员，开发人员，分析人员，测试人员和其他人员所广泛使用，可根据公司的需要自定义

版本：在一个项目上，一般会有多个版本，如：1.0alpha、1.0beta、1.0、1.2、2.0。影响版本— 可以清晰地反映出这个问题在哪个版本中出现错误。例如, 一个软件的缺陷可能影响了产品的1.1和1.2版。修复版本— 可以反映出报告的问题将在哪个版本，或已经在哪个版本中修复了。例如, 软件缺陷影响了产品的1.1和1.2版，这个缺陷已经在2.0版中修复了。注意没有修复版本的问题会被归类到'未规划'。，迭代的过程可以使用

项目模块：一个项目模块是这个项目中问题的逻辑分类集合。每个项目都可以根据你企业组织的要求设置多个模块 (也可以不设置模块)。我们对他的应用主要是不同业务线里面系统子模块

看板

搜索

. 安全

. 通知

8. 集成

如下图所示，在Jira中可以对问题处理过程中，根据不同的阶段定义不同的问题状态，但是须知底层的状态就三种分别是”待办” “处理中” 和 “完成”，我们所根据不同项目实际定义的问题状态名称都将对应到这三种底层状态。

解决问题完成而解决结果为“未解决”的问题

BUG 或 问题 级别定义

An issue has a priority level which indicates its importance. The currently defined priorities are listed below.

定制问题处理流程：

Jira中的批量操作

针对项目可自定义工作流，影响项目内Issues的流转状态和阶段，不同的问题类型可设置不同的workflow；

创建工作流→创建工作流方案→项目引用工作流方案

创建工作流

配置入口：Jira右上角的【设置】→ 问题 → 工作流

点击”添加工作流“弹出【添加工作流】的弹窗，输入新工作流的名字（注意名称只能是ASCII字符，不能输入汉字）和描述，点击”添加“进入【工作流设置】页面。

【工作流设置】页面中”添加状态“就是工作流中的issue的状态，”添加转换“就是在issue到达某个状态前需要点击的”转换“按钮；

如下案例：Start是转换，在issue页面点击”start“就能到达"IN PROGRESS"状态。

在”转换“上可设置条件，即要达到某种条件才可点击这个转换按钮；

也可在”转换“上设置界面，即点击”转换“按钮后先进入某个界面，在这个界面继续操作后可达到下个状态。

入口：工作流方案→添加工作流方案

进入设置【工作流方案】页面，点击右上角”添加工作流“→添加现有，选择刚创建好的Workflow；

点击"分配"将工作流关联到问题类型上（可关联到某一个问题类型，也可全部关联）；

字段：针对项目可自定义字段，也可以设置字段的属性：字段样式、显示/隐藏、是否必填；

自定义字段→配置字段→字段配置方案→项目引用字段配置方案

入口：自定义字段→添加自定义域→弹出【选择域类型】页面，根据需要选择字段类型并创建；

Tips：创建字段时，会让该字段关联到某个页面，直接忽略即可。

配置字段主要是将字段配置到”问题类型“和”项目“，则只有被配置的问题类型和项目才可以用该字段，默认”任何问题类型“都可使用该字段；

入口：点击字段右边设置→配置；

进入【配置字段】页面，点击方案应用内容“编辑配置”；

进入【修改配置方案内容】页面；

在【选择应用问题类型】模块指定该字段可被哪些“问题类型”使用；

在【项目】模块指定该字段可被哪些“项目”使用。

字段配置主要是配置字段的属性：是否必填项，是否隐藏掉以及关联的页面；

入口：字段配置→添加字段方案→弹出【添加域配置】，输入配置的名称和描述，点击“添加”；

进入【域配置】页面；

隐藏：表示在这个“字段配置”里不显示这个字段；

必选项：表示这个字段在这个“字段配置”中是必填项；

页面：字段在这个页面始终显示；

字段配置方案：是将创建好的“字段配置”关联到“问题类型”的配置方案；

入口：字段配置方案→选择域配置方案→弹出【选择域配置方案】弹出，输入字段配置方案的名称和描述，点击“添加”；

所有的问题类型的“字段配置”，系统会默认一个；点击“编辑”可以修改默认的“字段配置”，那么引用本字段配置方案的项目中的所有“问题类型”都会关联到该“字段配置”；点击“将字段配置与问题类型关联”，可单独设置“问题类型”对应的“字段配置”；

点击“将字段配置与问题类型关联”弹出【将域配置方案域问题类型关联】弹出，选择“问题类型”和对应的“字段配置”，点击“添加”即关联成功。

界面：针对项目自定义界面中显示的字段，对Issue的创建、编辑、查看操作界面进行字段的展示设置；

创建界面→创建界面方案→问题类型界面方案→项目引用问题类型界面方案

入口：界面→添加屏幕→弹出【添加屏幕】页面，输入界面的名称和描述，点击“添加”；

进入【配置页面】进行界面配置，即设置该界面显示哪些字段（字段的属性，在上面提到的”字段配置“中进行配置）；

页面底部输入字段，点击旁边的‘’添加“按钮进行添加；

将问题类型的操作（创建、编辑、查看）将创建的界面相关联；

入口：界面方案→添加屏幕方案→弹出【添加屏幕方案】页面，输入界面方案的名称、描述、默认页面，点击”添加“；

Tips：默认页面则代表点击所有问题类型的操作都显示该默认页面；

然后进入【配置页面方案】页面，点击右上角”把问题操作与屏幕相关联“，弹出【把问题操作与屏幕关联】页面，选择问题操作类型、对应的界面（刚创建好的界面），点击添加。

将问题类型与界面方案关联；

创建入口：问题类型界面方案→添加问题类型屏幕方案→弹出【添加问题类型屏幕方案】，输入方案名称、描述、选择刚创建的界面方案；

点击”编辑“可修改默认页面，即引用该方案的项目中所有的问题类型都是该”问题类型界面方案“；

也可点击”将问题类型与屏幕方案关联“，对问题类型指定”问题类型界面方案“；

点击”将问题类型与屏幕方案关联“，弹出【将页面方案与问题类型关联】，选择问题类型，选择对应的界面方案即可。

要给项目中的不同问题类型，创建不同用户界面首先得搞清楚Jira在界面这部分的逻辑。

分为三层，层层嵌套，

第一步、“界面”

如下图10-1可以在这里增加界面，就是配置界面上的不同的字段，在本例中建立了如下界面，但这个配置完之后并不知道这个界面使用在哪里。

① Scrum for TYYP（问题类型为 事项）

②Scrum for TYYP（问题类型为 故障 和 优化）

第二步、“界面方案“

增加界面方案，选择上一步创建的，”界面“ 相当于”界面方案“把”界面“包装了一层。在这一步这个界面方案仍然不知道用在何处生效。

① Screen Scheme for TYYP（问题类型为 事项）

②Screen Scheme for TYYP（问题类型为 故障 或 优化）

第三步、创建“问题类型界面方案”

在这一步，在将 多个“界面方案”打包成一个“问题类型界面方案”，并完成问题与界面方案的匹配。同时将"问题类型界面方案”与项目进行绑定

将项目与预先创建的方案关联

首先了解下看板、backlog、sprint、任务、发布版本的关系：

看板：分为两种：Kanban、Scrum看板；看板可以创建多个，每个看板下可以对应多个Sprint；

Backlog：所有创建的Sprint、任务都会在这里显示；意只有Scrum看板才有“backlog”菜单，所以我们一般创建Scrum类型的看板；

Sprint：即开发迭代，在Backlog菜单下创建Sprint，一般2-4周为一个Sprint周期，Sprint内可以关联多个任务、Story、bug等；

Active Sprints：只有开始的Sprint，才会在此菜单中显示；

Releases：创建stroy/任务时关联的修复版本/影响版本；

配置总流程

创建项目→添加workflow→添加界面方案→添加字段方案→设置Scrum看板泳道图→完成

优先级：Issue的优先级设置。

通常业务部门出BRD，产品部门出PRD，并在需求池Backlog里面放置用户产品故事（Story），大的模块（Epic）包含多个小的产品故事。

需求评审后，技术leader和测试leader对当前需求没有疑意之后，当场给出开发排期与测试排期。我们得到一个预上线时间，根据这个时间我们建立这个项目版本Sprit。

这个项目Sprint中的所有Task都是基于我们产品部门的用户故事进行的；例如：1个产品故事，包含前端页面开发的task、后端接口的task、测试用例的编写。

各个职能部门、前端组、后端组、测试组、运维组、配管组建立每周周sprint（周计划），周sprint又与各条产品线的sprint中的task进行关联。

介绍一下新项目的添加以及设置。

问题类型配置

项目添加好之后，JIRA 默认的是 Bug 类型，而我们要进行的是管理敏捷开发流程，因此需要对应于敏捷开发中的 Task，这就需要手动的修改一下默认的 Issue 及 Issue 的顺序。

工作流

JIRA 默认工作流为5个状态：Open，Close，Resolve，In Progress，ReOpen。可以根据项目需要定义

自定义工作流完成后。接下来还需要在配置一下工作流方案。

导入事项

还可以保存一个配置

{

"config.version" : "2.0",

"config.project.from.csv" : "false",

"config.encoding" : "UTF-8",

"config.email.suffix" : "@",

"config.field.mappings" : {

"附件" : {

"jira.field" : "attachment"

},

"提出人" : {

"jira.field" : "reporter"

},

"评审意见或任务描述" : {

"jira.field" : "summary"

},

"Owner" : {

"jira.field" : "assignee"

},

"完成日期" : {

"jira.field" : "updated"

},

"工作关闭结论描述" : {

"jira.field" : "comment"

},

"问题类型" : {

"jira.field" : "issuetype"

},

"提交日期" : {

"jira.field" : "created"

},

"会议" : {

"existing.custom.field" : "10201"

}

},

"config.value.mappings" : { },

"config.delimiter" : ",",

"config.project" : {

"project.type" : null,

"project.key" : "UMSP",

"project.description" : null,

"project.url" : null,

"project.name" : "YYTD项目名称",

"project.lead" : null

},

"config.date.format" : "yy/MMM/dd"

}

导入成功的提示

Jira Software Cloud support | Jira Software Cloud | Atlassian Support

Advanced search reference - JQL fields | Jira Software Cloud | Atlassian Support

Kanban起源于1950年代的丰田看板系统（或方法）；它很好的应用在生产制造系统中，Kanban的工作模式是从消费端（如零售店）来拉动（pull）生产部件、零件的实时流动，通过看板（卡片）的记录和传递，可以发现整个生产制造流程的瓶颈，尽可能减少各个生产、仓储环节的库存和浪费，从而实现JIT（Just-In-Time，即时）与精益（Lean）生产和制造。同样Kanban的工作模式和思想也很好的应用到软件行业。专为软件团队中的每位成员而构建、可用于规划、跟踪和发布任务协助工作JIRA Software提供了对敏捷方面的强大支持。在JIRA Software中提供了Board功能，Board分为两类，一类为Scrum，另一类为Kanban。Scrum的方式主要目标是在固定的时间周期内能充分地利用资源，尽可能多的向客户交付可使用的产品。Kanban的主要目标是尽快地加速工作的流转，尽可能早的向客户交付可使用产品。因此，当我们团队在使用Kanban的方式开展工作时，对团队的考核指标也应当依据尽可能早的原则。在JIRA Software的Board中，提供了控制图，可以让我们了解团队在这一方面的能力和发展趋势。我们看一下控制图的各项数据指标，并对其中的各项进行说明

在以上图中，向我们展示了一段时间内使用此Baord的团队在处理问题速度上面的指标；这些指标指标包括问题处理量是指在这一段时间内，总计有多少个任务处理完成平均处理周期指所有问题处理的的平均周期；如有三个任务，分别花费了3天，5天，8天，那么平均周期为5.2天=(3+5+8)/3；在图表中用一条红色横线表示；平均处理周期主要考查团队在此时间段内工作能力的平均水平。平均移动周期指每一个任务或者问题集前几个完成的任务或者问题及以及此后几个完成的任务及任务集的平均值和当前问题的解决周期的平均值；比如当前问题花费了3天完成，前面完成的两个任务分别为4和5天，后面完成的两个任务分别为5和6天，那么平均移动周期即为4.6天=(4+5+3+5+6)/5；在图表中以深蓝的曲线来表示；平均移动周期主要考查团队工作的当前能力的平均水平。标准方差指每一个任务前后各几个任务的解决周期计算出来的标准方差时间；比如当前问题花费了3天完成，前面完成的两个任务分别为4和5天，后面完成的两个任务分别为5和6天，那么它们的平均周期为4.6天；那么标准方方案为1.04天；标准方案主要考核团队工作情况的稳定性。通过对以上图以及指标各项，我们可以了解团队的当前水平、某一段时间的平均水平以及团队整体的稳定性；那么什么样的图可以表示团队能力较好或者较差呢？从Kanban追求的目标以及结果中，我们可以这么认为1、平均线越低越好2、标准方案的范围越小越好，并波动较小3、平均移动线持续性的向下从以上图中，我们可以了看到团队在前期和中期有不稳定的情况，但在后期持续性的向好。当然，在我们工作中可能有一些不稳定的因素是由于误操作、或者任务被遗忘未来的及修正状态引起来的，比如一个任务实际上完成了但负责人请假一直未关闭，导致数据异常。我们从图表中也可以看到这类数据，比如在以上图表中那些处理时长过大的圆点，我们可以点击它来查看详情。但这类数据如何从我们的统计报表中排除掉，修正我们的报告并了解真实的实际情况呢？我们可以使用控制图中的相关设置，设置项包括时间尺度、列、快速过滤、非工作时间。以下将说明各设置的使用方法。1、时间尺度我们需要统计的一段周期，可以按一周、二周、一月、一季度、半年来快速设定，也可以自定义任意的时间周期。2、列可以简单的理解为我们处理任务的各个阶段，在JIRA Software的面板中，有单独页来对它进行定义，一般可以将它与我们处理任务的工作流的各个状态一一对应(我们也强烈建议这么使用，好处是我们可以清楚的了解工作的整体进展，同时也可以分析各个流程环节哪些会现出瓶颈，以及时调整资源、工作方法或者调整WIP)。3、快速过滤是指我们面板中快速过滤的设置，它用于将面板中的数据按规则进一步地筛选。在控制图中对异数据的过滤，可以使用此功能；在面板的配置中也专门有此项的配置页。4、非工作时间是用于排除掉我们节假日的时间，通过它的设置可以将处理周期的时间排除掉那些非工作时间；在面板的配置中也专门有此项的配置页。介绍了以上控制图的配置项，那些排除工作中的异常项，我们可以使用快速过滤的方法；对于异常数据，我们可以将这些数据加上统一的标签，比如label=异常；然后通过面板的配置页“快速过滤”来定义一个过滤项，如下图

之后，我们可以在控制图的配置项中将此快速过滤出的任务排除到控制图统计之外，如下图

之后，我们可以观察到在控制图中统计的数据范围内将不包括异常数据，图表的显示将出现相应调整。当然，通过修改报告的配置项，我们也可以了解工作流中几列组合，或者单个列的处理周期情况（即查看多个状态或者单个状态），比如我们想看In Progress的状态下的处理周期，可以单独选中它，如下图

这样，我们即可以看到控制图中关于In Progress状态下的数据处理的速度和发展趋势了。控制图有力地、直观地展示敏捷团队稳定性及能力趋势，对于我们提高团队的敏捷成熟度，并展开对工作的回顾和分析提供了很好的支持。大家有在玩Kanban么？那么快使用JIRA Software的控制图，看看我们的团队情况吧。以下是对控制图的几个常见问题的说明什么是周期时间(Cycle time)和交付时间(leadtime)？周期时间是指在一个问题上工作的时长，它通常是从问题开始处理时间到这个问题处理结束时间之间的时间差，这个时间是指自然时间。如果这个问题处理结束后又重新打开再次处理，这个时间也是会进行累积的。交付时间与周期时间差不多，但交付时间包括这个问题从创建到开始时间这个时间差，即这个问题从创建时间到完成时间这个的总时长。在控制图中，周期时间可以是连续的也可以是时断时续的，这依据我们在报告参数设定所选择的列项。处理周期是如何确定的？用于计算周期时间的状态取决于项目使用的工作流。我们可以在控制图中进行配置，决定哪些状态上停留的时间可以计入处理周期。比如在工作流中有一个为代码Review的状态，在这个时间上停留了18个小时（根据业务规则这代码Review不包括在处理周期中），那么可以在控制图中去掉此节点，那原来的处理周期时间将减去18小时。处理周期的计算在控制图中主要是针对列，如果此列映射了多个状态，而有一个状态我们并不希望参与处理周期计算，我们就需要对面板中的列进行调整（将一列中多个状态进行分开为多列，我们建议一个状态一列）。移动平均周期是如何计算的？移动平均值（图表上的蓝色线）是基于问题的，不是基于时间的。每一个问题都显示在图表，移动平均值（在那个时间点上）通过问题本身计算的，计算公式为前N个问题的周期处理和后N问题的周期的平均值加上本问题（N总是为偶数的，并且最小值为2）；例如：前面取2个问题A和B，处理周期为2和3天，后面取2个问题D和E，处理周期分别为1和3，当前问题的处理周期为4，那么它的移动平均周期为：(2+3+4+1+1)/5=2.2天；这种方法产生一个稳定的移动平均线，它能更好地显示异常值（即移动平均值不会大幅偏离离群值）。移动平均线也容易理解，因为变化是由于问题的位置引起来的；移动平均值的计算是基于问题的个数，个数会依据我们选定周期的时间长短以及在这周期时问题的密度。蓝色阴影区域代表什么？控制图的蓝色阴影区域表示标准偏差，即实际数据与移动平均值的变化量。标准方差偏差会显示出我们的问题的处理的平均能力。例如，如果有一个窄的蓝色波段（低标准偏差），我们就可以确信未来问题的周期时间将接近这个移动平均值。标准方差如果在平均线下方，基本可以预示未来我们的平均能力将会有所提高，但还是需要注意移动平均时间的走向。图表上的点代表什么？每个点代表一个问题或一组（组）问题。点的垂直位置代表问题的移动周期，即“经过多长时间”。对于一组问题，点被放置在问题的平均周期时间内。PPT资源下载地址：92G10SA3

总结：

通过 JIRA，使得我们能够快速的实施敏捷开发，自动化的管理敏捷开发中的各个环节，使我们能够把精力集中到业务的实现、技术点的攻克上。

项目经理必备工具箱文档模版下载：1RPT39Q8 1RPT39Q81RPT39Q81RPT39Q81RPT39Q8https: //8ma.co/res/1RPT39Q8